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(54) Demultiplexer for a digital video receiver 

(57) The present invention relates to the demulti- 
plexing of a digital data stream in a receiver so as to 
retain only those parts of the digital data stream required 
by the receiver. Such demultiplexing is particularly use- 
ful when applied to a receiver circuit in a television sys- 
tem having a digital set -top-box. 

A memory in the receiver stores packet identifiers 
of data packets required by the receiver, which are 
stored in the memory under the control of a first control 



circuit. A second control circuit extracts packet identifi- 
ers from incoming data packets in an input digital data 
stream. A third control circuit receives the extracted 
packet identifier and determines whether this matches 
one of the packet identifiers stored in the memory. A 
match signal is set by the third control circuit to the sec- 
ond control circuit responsive to a match. The second 
control circuit demultiplexes the input data packet re- 
sponsive to the match signal. 
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Description 

[0001] The present invention relates to demultiplexing 
of a digital data stream in a receiver, so as to retain only 
those parts of the digital data stream required by the 
receiver. The invention relates particularly but not exclu- 
sively to such a receiver circuit in a television system 
having a digital set-top-box receiver. 
[0002] In digital television systems, a television is pro- 
vided with a set-top-box to receive and decode a broad- 
cast digital data stream which contains programme in- 
formation for display on the television. The broadcast 
digital data stream may arrive at the set-top-box via a 
satellite or cable system, via a digital terrestrial system, 
or via a disk or tape. A disk or tape, such as a CD ROM 
drive in a personal computer, may provide digital video 
information for display on a monitor 
[0003] There are various known standards for digital 
video broadcasting (DVB) and one now commonly used 
standard is the MPEG-2 standard. 
[0004] In the MPEG-2 DVB standard data is encoded 
into transport packets. Each transport packet is defined 
by the standard as consisting of 188 bytes, comprising 
4 header bytes and 184 payload bytes ("the data pay- 
load"). For transmission, the transport packets are time 
division multiplexed into a transport stream. At the re- 
ceiver in the set-top-box, the transport stream is demul- 
tiplexed to recover the transport packets. Optionally the 
transport packets may be scrambled and encoded with 
error correction information for transmission, and then 
desc ram bled and error-checked at the receiver. 
[0005] The data payload in the transport packets is, 
according to the MPEG-2 standard, one of two types. 
The first type is known as a packetised elementary 
stream (PES), and the second type is known as program 
specific information (PSI). 

[0006] The packetised elementary streams (PESs) 
form the video, audio and private data information of the 
broadcast. The MPEG-2 transport stream is made up of 
one or more PESs (either video, audio or private). The 
MPEG-2 transport stream is primarily intended for the 
transport of TV programmes over long distances. This 
type of stream can combine, in the same multiplex, 
many programmes, each of them being composed of 
one or more PESs. In order that the receiver can cope 
with this mix of programme information, the MPEG-2 
standard defines four types of tables, which together 
make up the MPEG-2 program specific information 
(PSI). 

[0007] Each table of the PSI is made up of one or more 
sections, there being a maximum of 256 sections for 
each table. The MPEG-2 tables are defined in the stand- 
ard, and include a program allocation table, a program 
map table, a conditional access table and private tables. 
The European DVB standard additionally defines com- 
plementary service information tables. The basic serv- 
ice information tables are the network information table, 
service description table, event information table, and 



time and date table. The optional service information ta- 
bles are the bouquet association tables, running status 
tables, and stuffing tables. Each section includes an op- 
tional cyclic redundancy code (CRC) check. 

5 [0008] A PES packet always starts at the beginning 
of the payload part of a transport packet and ends at the 
end of the transport packet. Sections, however, do not 
necessarily start at the beginning nor finish at the end 
of a transport packet. For a section, the transport packet 

10 can start with the end of another section. 

[0009] At each decoder or set-top-box ; the transport 
stream is decoded. To achieve the decoding of the trans- 
port stream, each set-top-box is provided with a trans- 
port interface, which provides an interface between the 

is transport stream input to the box and the actual MPEG- 
2 decoders which decode the audio and video informa- 
tion and sections broadcasts. 

[0010] The transport interface demultiplexes the 
transport stream to retain only those transport packets 

20 which are required by the particular set-top-box for de- 
coding. The transport stream is a set of different servic- 
es time division multiplexed, and the purpose of the 
transport interface is to demultiplex them. At a front input 
end of the transport interface, a time demultiplex func- 

25 tion is performed to separate the transport stream into 
its component transport packets. 

[0011] Each transport packet has associated there- 
with in its header a packet identifier (PID) which identi- 
fies the type of packet and various information associ- 

30 ated with the data in the packets including the type of 
packet (PES or PSI). Each particular receiver or set-top- 
box is only interested in receiving packets having packet 
identifiers of interest to the particular set-top-box, for in- 
stance those associated with a particular television pro- 

35 gramme selected for viewing. Thus once the incoming 
transport stream has been time demultiplexed to recov- 
er the transport packets, it is necessary to further de- 
multiplex the transport packets to retain only those hav- 
ing packet identifiers required by the receiver. 

40 [0012] The transport interface merely uses the header 
of PES transport packets to demultiplex them, and 
stores the data payload of the demultiplexed packets in 
the memory. The transport interface similarly demulti- 
plexes PSI transport packets, but then filters the sec- 

45 tions of the demultiplexed packets to retain only sections 
required by the receiver, before storing the filtered sec- 
tions in the memory without any further processing. 
[0013] Although the MPEG-2 DVB standard is one of 
the main digital video broadcast standards, there are 

50 variations within the standard. It is desirable to provide 
receivers having decoders which are generally as flex- 
ible possible not only tocope with variations in the stand- 
ard but, if necessary, to enable the receiver to be used 
with a different standard. 

55 [0014] It is therefore generally desirable to provide a 
single receiver which provides the flexibility of enabling 
different types of digital video broadcast standards to be 
used by utilising a programmable transport interface. 
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Utilising such a receiver in a set-top-box may enable the 
set-top-box to be switched between two or more types 
of syntax format associated with different standards in 
situ. 

[001 5] There are known techniques for performing the 
demultiplexing of the time multiplexed MPEG-2 trans- 
port packets. One known technique is an application 
specific integrated circuit (ASIC) hardware implementa- 
tion in which a dedicated hardware design parses the 
transport packets with no flexibility That is the packet 
identifiers of the incoming transport packets are passed 
to a custom circuit block which detects whether the PID 
of the incoming transport packet matches any of the 
PIDs associated with a particular receiver. A major 
drawback of this hardware custom solution to the de- 
multiplexing of transport packets is the lack of flexibility 
in syntax parsing. Although it is possible to select the 
PID numbers to be searched for in the custom circuit, it 
is not possible to alter the algorithm applied in the cus- 
tom circuit once it has been set up. Thus, there is no 
flexibility to allow for the change in behaviour of the re- 
ceiver on the incoming digital data stream. This heavily 
reduces the lifetime of each chip, its range of applica- 
tions, and its general ability to react to changes in stand- 
ards or even requirements. 

[0016] A second known technique for demultiplexing 
of MPEG-2 transport packets is that based on the main 
processor CPU of the receiver set-top-box, in which a 
program runs on the CPU for performing the demultiplex 
operation. Such an operation gives full flexibility of al- 
gorithms, with the PIDs associated with the receiverand 
to be searched for stored in the main processor CPUs 
memory. Thus, this gives full flexibility of algorithms in 
that the contents of the CPU main processor memory 
can be readily changed. However, this requires the main 
processor CPU to carry out itself directly the demulti- 
plexer operation, which places a heavy load on the CPU. 
This limits the availability of the main processor CPU to 
perform other operations for running the set -top-box. As 
the amount of operations required to be performed by 
the set-top-box increases, together with the increasing 
complexity of those operations, this demand on the 
processing power of the main processor CPU becomes 
increasingly undesirable. 

[001 7] It is therefore an object of the present invention 
to provide a programmable transport interface in which 
the demultiplexing of the incoming data stream is pro- 
grammable to so as to enable dilferent standards to be 
multiplexed without placing a burden on the main proc- 
essor of the decoder. 

[001 8] According to the present invention there is pro- 
vided a receiver for demultiplexing a digital data stream, 
the digital data stream including data packets each hav- 
ing a packet identifier, so as to retain only those data 
packets required by the receiver the receiver compris- 
ing input circuitry for inputting the digital data stream, a 
memory for storing all packet identifiers of data packets 
required by the receiver, a first control circuit for control- 



ling the storage in the memory of the packet identifiers, 
a second control circuit for extracting a packet identifier 
from a data packet in the digital data stream input to the 
input circuitry and a third control circuit for receiving the 
5 extracted packet identifier and determining whether 
such matches one of the packet identifiers stored in the 
memory, and for setting a match signal to the second 
control circuit responsive to a match, wherein the sec- 
ond control circuit demultiplexes the input data packet 
10 responsive to the match signal. 

[0019] The invention also provides a method of de- 
multiplexing a digital data stream input to a receiver, the 
digital data stream including data packets each having 
a packet identifier, so as to retain only those data pack- 
75 ets required by the receiver, comprising the steps of in- 
putting the digital data stream, storing in a memory, un- 
der the control of a first control circuit, all packet identi- 
fiers of data packets required by the receiver, extracting, 
under the control of a second control circuit, a packet 
20 identifier from a data packet in the input digital data 
stream, determining, under the control of a third control 
circuit, whether the extracted packet identifier matches 
one of the stored packet identifiers, setting a match sig- 
nal responsive to a match determined by the third con- 
25 trol circuit; and demultiplexing, under the control of the 
second control circuit, the input data packet responsive 
to the match signal. 

[0020] The invention will now be described with refer- 
ence to the accompanying drawings, in which: 

30 

Figure 1 illustrates a portion of a transport stream; 

Figure 2 illustrates in block schematic form a pro- 
grammable transport interface; 

35 

Figure 3 is a block diagram of the transport control- 
ler of the programmable transport interface accord- 
ing to a preferred implementation of the present in- 
vention; 

40 

Figure 4 is a block diagram of the search engine of 
the transport controller of Figure 3; 

Figure 5 illustrates schematically the advantageous 
^5 interconnection of arrays, associated with transport 
packets, in the memory of the programmable trans- 
port interface of Figure 2; and 

Figure 6 illustrates a digital broadcast system incor- 
50 porating a programmable transport interface ac- 
cording to the present invention. 

[0021] In the following description the present inven- 
tion is described with reference to an exemplary embod- 
55 jment in which an MPEG-2 transport stream is demulti- 
plexed in a programmable transport interface of a re- 
ceiver in a digital set-top-box. It will be apparent, how- 
ever, that the present invention is not limited to such an 
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application and does in fact have broader applicability 
to other types of digital data and other types of applica- 
tion. 

[0022] Figure 1 illustrates a portion of a transport 
stream 1 which is composed of a series of N transport s 
packets 2. Each transport packet 2 comprises a trans- 
port packet header 4 and a transport packet payload 6. 
The transport stream is a bit stream which carries in the 
transport packet payloads 6 information for recreating, 
for example, a number of different television pro- 10 
grammes. The transport stream is formed by source en- 
coding the television programmes. The transport stream 
is then typically channel encoded for transmission (by 
satellite or cable) and channel decoded on its reception 
to reproduce the transport stream. The transport stream is 
is then source decoded to recreate a selected one of the 
different television programmes. Each particular televi- 
sion programme requires three types of information (au- 
dio information, video information and tables of pro- 
gramme information) for its recreation. Each transport 20 
packet 2 is preferably associated with a particular tele- 
vision programme, a particular source encoding time 
and a particular one of the information types. The indi- 
vidual transport packets are time division multiplexed to 
form the transport stream and allow the real-time recre- 2$ 
ation of any one of the different television programmes 
from the transport stream. To recreate a television pro- 
gramme the transport stream is sequentially demulti- 
plexed to recover only the transport payloads 6 of audio 
information, video information and tables of programme 30 
information which are associated with the selected tel- 
evision programme. The recovered payloads are then 
decoded and used to recreate the television pro- 
gramme. 

[0023] According to the MPEG-2 digital video broad- 35 
cast (DVB) standard each of the transport packets 2 is 
188 bytes long and the transport packet header 4 is 4 
bytes long. The transport packet payload 6 contains ei- 
ther audio or video information or sections. The sections 
are parts of tables. The audio and video information and 40 
the sections in the payloads 6 are packetised and en- 
coded in accordance with the MPEG-2 DVB compres- 
sion standard. 

[0024] A programmable transport interface 10, illus- 
trated in Figure 2, is used to process a transport stream 45 
1 and produce a data output stream 506 suitable for re- 
constitution as a television programme after MPEG-2 
decoding by MPEG-2 decoders (not shown). The pro- 
grammable transport interface 1 0 is included in a receiv- 
er which receives the transport stream 1 . so 
[0025] The transport packet header 4 contains a syn- 
chronisation byte which identifies the beginning of each 
transport packet 2. The transport packet header also 
contains a packet identification (PID) which identifies 
the information type and the television programme as- 55 
sociated with the transport packet payload 6. The trans- 
port packet 2 also contains information identifying the 
source encoding time of the transport packet. The trans- 



6 

port packet header 4, including the synch ronisation byte 
and the PID, is not scrambled. The transport packet pay- 
load 6 may be scrambled. 

[0026] The programmable transport interface (PTI) 10 
performs various functions including: 

i) using the synchronisation byte to identify the start 
of a transport packet 2; 

ii) using the packet identification (PID) to identify, 
amongst other functions, the type of information 
contained in the packet (i.e. audio or video informa- 
tion or sections) and the television programme it 
represents; 

iii) descrambling the transport packet payloads 6; 
and 

iv) demultiplexing the transport stream 1 to produce 
a data output stream 506. 

[0027] The data output stream 506 comprises a 
stream of audio information associated with the selected 
television programme, a stream of video information as- 
sociated with the selected television programme, or ta- 
bles of programme information associated with the se- 
lected television programme. The PTI outputs these 
streams to the necessary MPEG-2 decoders to repro- 
duce the selected television programme 
[0028] The programmable transport interface 1 0 com- 
prises five primary functional blocks: an input module 
100; a transport controller 200; an instruction SRAM 
(static RAM) 300; a data SRAM (static RAM) 400; and 
a multi-channel DMA (direct memory access) controller 
500. 

[0029] The input module 100 receives the transport 
stream 1 , and outputs an alternative output stream 1 06. 
The input module 100 identifies the synchronisation 
byte of each transport packet which is used to synchro- 
nise the system clock and the transport stream. The in- 
put module 100 is controlled by the transport controller 
200 via an input module control signal 112 which in- 
cludes a descrambling control signal 114, an alternative 
stream control signal 1 1 6 and output stream control sig- 
nals 118. The input module 100 provides bits to the 
transport controller 200 via an interconnect 108 and it 
receives bits back from the transport controller 200 via 
the interconnect 110. The input module, under the con- 
trol of the transport controller 200 via the input module 
control signal 1 1 2, descrambles the payload 6 of select- 
ed transport packets 2 and supplies the selected de- 
scrambled payloads to the transport controller 200 via 
the interconnect 108. The descrambling of the payloads 
is controlled by the descrambling control signal 1 1 4 sup- 
plied by the transport controller 200 and the number and 
rate of bits supplied on the interconnect 1 08 is controlled 
by the output stream control signal 1 1 8. The input mod- 
ule 100 receives, along the interconnect 110, bits from 
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the transport controller 200 which may be output as the 
alternative output stream 106 under the control of the 
alternative stream control signal 116. 
[0030] The transport controller 200 operates on the 
bits received on interconnect 10S from the input module 
1 00. The transport controller 200 receives from the input 
module 100 via interconnect 108 the transport packet 
header 4 of the transport packet 2 arriving at the trans- 
port stream input interface 102. The transport controller 
200 uses the packet identifier (PID) in the transport 
packet header 4 to determine whether the transport 
packet 2 now entering the input module 100 is associ- 
ated with a selected television programme for the pro- 
grammable transport interface 10. If it is not, the re- 
ceived transport packet 2 is discarded. If it is, it controls 
the input module 100 to descramble (if necessary) the 
transport packet payload (as described above), and to 
supply the transport packet payload 6 via the intercon- 
nect 108 to the transport controller 200. The transport 
controller 200 may pass a payload 6 associated with au- 
dio or video information for the selected programme 
straight to the transport controller output 502. If the pay- 
load 6 relates to a section of a table the transport con- 
troller 200 may further process the information before 
providing it at its output 502. Alternatively the transport 
controller 200 may process the received pay loads 6 and 
repacketise them in accordance with a different trans- 
mission standard. The reformatted transport stream is 
then provided to the input module 100 via the intercon- 
nect 1 1 0 and it is output as the alternative output stream 
106 under the control of the alternative stream control 
signal 116. 

[0031] The transport controller 200 comprises a trans- 
port processor (not shown) which reads instruction sets 
from the instruction SRAM 300. The transport controller 
200 is connected to the SRAM 300 by interconnect 304 
and it reads its instructions via the interconnect 304. A 
system processor (not shown) may read and write to the 
instruction SRAM 300 via a system interconnect bus 
402. However, the transport controller 200 has prefer- 
ential access to the instruction SRAM 300 determined 
by an arbiter (not shown) which arbitrates between ac- 
cesses by the transport controller 200 and the system 
processor. The system processor may also access the 
transport controller 200 via the system interconnect bus 
402. 

[0032] The data SRAM 400 can be accessed by the 
processor of the transport controller 200 via the inter- 
connections 404 and 406. The processor of the trans- 
port controller uses the interconnection 404 to read from 
and write to the data SRAM 400. A search engine within 
the transport controller 200 reads from the data SRAM 
400 along interconnection 406. The search engine 
searches the data SRAM 400 for the packet identifier 
(PID) in the incoming transport packet header 4. If the 
packet is not to be discarded, then the PID for that pack- 
et will have been stored in the data SRAM, and is located 
by the search engine of the transport controller. Associ- 



ated with each PID in the data SRAM is a plurality of 
pointers, which point to other addresses in the data 
SRAM where other information associated with the in- 
coming transport packet is stored. The search engine 

5 retrieves a pointer stored with a particular PID for use 
by the transport controller processor. The transport con- 
troller processor then uses the pointers to access all the 
information it needs to process the payload of the in- 
coming transport packet. The pointers may : for exam- 

10 pie: point to descrambling keys for use by the input mod- 
ule 100; point to addresses for use by the DMA controller 
500; identify whether the payload is video or audio in- 
formation or sections, identify whether the payload is 
special data to be output on alternative output stream 

1$ 106; or locate information for masking the search filter 
etc. A detailed description of the operation of the search 
engine of the transport controller 200 in reading the data 
SRAM 400 is given hereinafter. 

[0033] This information enables the transport control- 
20 |er to generate the input module control signals 112 as 
appropriate, and control the processing, if any, of the 
bits received on interconnect 108. 
[0034] The transport controller 200 produces a trans- 
port controller output 502 which is supplied to the multi- 
25 channel DMA controller 500. The multi-channel DMA 
controller 500 supplies the data output stream 506, in- 
directly, to the MPEG-2 decoders (not shown). A full de- 
scription of the DMA controller 500 can be found in co- 
pending application No. (PWF Ref: 
30 85018). 

[0035] The system processor writes to each of the in- 
struction SRAM 300, the transport controller 200 and the 
data SRAM 400 via the system interconnect bus 402. 
The instruction SRAM 300 can only be written to by the 

35 system processor: the transport controller can only read 
from, and not write to, its own instruction SRAM 300 via 
the interface 304. The system processor can also read 
from the instruction SRAM. An arbiter is provided to ar- 
bitrate between accesses to the instructions SRAM 300 

40 by both the system processor and the transport control- 
ler 200. 

[0036] The system processor, via the system inter- 
connect bus 402, and the transport controller 200 via 
interface bus 404, can both read and write to the data 

45 SRAM 400. The search engine of the transport control- 
ler 200 can only read from the data SRAM 400 via in- 
terface bus 406. An arbiter is provided to arbitrate ac- 
cesses to the data SRAM 400 by each of the system 
processor, the transport controller 200, and the search 

so engine within the transport controller 200. Access to the 
data SRAM 400 is arbitrated with the following order of 
priority : the search engine within the transport controller 
200 has highest priority, the transport controller proces- 
sor next priority, and the system processor lowest prior- 

55 ity. The transport controller may be reset by the system 
processor by a reset signal on the interface bus 302. 
[0037] The system processor, via system intercon- 
nect bus 402, and the transport controller 200 via the 
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bus 404, can both read and write to registers within the 
DMA controller 500. An arbiter is provided to arbitrate 
between the system processor and transport controller 
access to the DMA controller 

[0038] The system processor via system interconnect s 
bus 402 also accesses registers within the transport 
controller 200, to read and write thereto. 
[0039] The system processor initially writes to the in- 
structions SRAM 300 : the data SRAM 400, and registers 
within the transport controller 200 and the DMA control- 10 
ler 500. to configure them. 

[0040] Referring now to Figure 3, there is shown a 
block diagram of the main components of the transport 
controller 200 of the programmable transport interface 
10. 75 
[0041] The mam elements of the transport controller 
200 are a transport controller core 320, a section filter 
312. an input register 316. an output register 318, an 
input counter 3 1 C an output counter 31 4, and a search 
engine 322 20 
[0042] The nput icytMoi 316 receives the bits on the 
interconnect 10c nnd outputs them on lines 326 to both 
the transport controicr core 320 and the section filter 
312. The input regctcf 316 filso provides an input on 
lino 324 to the tnoul counter 310. and in turn the input 2£ 
counter 310 p-ovdos h-> input on line 336 to the trans- 
port controller core 320 *nd section filter 31 2. The trans- 
port controller co#c 320 hns bi-airectional connections 
328 to the section *.rtrr 31? In addition, and as de- 
scribed hereinabove with reference to Figure 2, the 30 
transport controller core 320 is connected to the instruc- 
tion SRAM via the interconnect 304, and is connected 
to the system processor via the system interconnect bus 
402 The transport controller core also accesses the da- 
ta SRAM 400 via r»tcrconnecttons404, the interconnec- 35 
tions 404 also being connected to the search engine 
322. The search engine 322 accesses the data SRAM 
400 via the interconnections 406 The transport control- 
ler core provides nn output on lines 332 which forms an 
input to the output rcgisicr 3 1 6, the output register 31 8 40 
providing the output signals on interconnect 502. The 
output register 318 niso provides a signal on line 334 
which provides an input tc the output counter 314, the 
output counter 314 m turn providing an output on signal 
line 330 to the transpor : controller core 320 and the sec- 45 
tion filter 312 Tho socton titter 312 also has an output 
connected to the line 332 to lorm an input to the output 
register 318. Tho bucimn lifter c*in be accessed by the 
system processoi vtn ir kj *>y*>tern interconnect bus 402. 
The transport controller core 320 also outputs the sig- so 
nals 1 1 2 and the signal 1 1 0 directly to the input module 
100. 

[0043] As mentioned hereinabove, the transport con- 
troller 200 initially rocovos from the input module 100 
via interconnect 10c the transport packet header 4 of ss 
the transport packet 2 ^rrrvmg at the transport stream 
input interface 102 Tho transport packet header 4 is in- 
put to the transport controller core 320 via the input reg- 



ister 316. The transport controller core 320 includes the 
transport processor. As also discussed hereinabove, 
the transport packet header includes the packet identi- 
fier (PID) which identifies the information type and the 
television programme associated with the transport 
packet payload 6. According to the present invention, 
the PID is used to demultiplex the arriving transport 
stream. That is, the transport controller core 320, as will 
be described in detail hereinafter, uses the PID of the 
transport packet header to determine whether the trans- 
port packet should be retained or discarded by the pro- 
grammable transport interface 10. If the transport pack- 
et is to be retained, then the transport controller core 
further uses the PID to determine whether the transport 
packet can be passed straight through the transport 
controller 200 to its output interface 502, or whether 
some processing or further action on the transport pack- 
et is necessary before transference to the output inter- 
face 502 of the transport controller 200. 
[0044] The operation of the section filter 312, output 
counter 314, and input counter 310 are not relevant to 
the discussion of the present invention, and for a full de- 
scription of the operation of such elements reference 
should be made to copending application Nos. 

(PWF References 85013 and 

85019) 

[0045] The PID constitutes a certain number of bits of 
the transport packet header, and particularly in the pre- 
ferred embodiment of the present invention in which the 
transport packet conforms to the MPEG-2 standard the 
PID constitutes 13 bits of the transport packet header. 
The bit locations of the PID will, in accordance with the 
MPEG-2 standard, always be in the same location of a 
transport packet header. 

[0046] The data SRAM 400 includes therein a set of 
memory locations which are reserved, each memory lo- 
cation storing a possible valid value of the PID, that is 
one of those values of the PID for which the incoming 
transport packet should be retained because the data 
payload associated with the packet is required by the 
receiver. All possible values of the PID are stored in this 
reserved area of memory. Stored with each possible val- 
ue of the PID, is the necessary information associated 
therewith for the transport controller core 320 to deter- 
mine how to process the transport packet, if at all. 
[0047] The main processor can access the data 
SRAM 400 via main processor bus 402 to change the 
valid values of the PID, thus enabling the demultiplexing 
operation to be changed. Prior to operation of the pro- 
grammable transport interface, the main processor 
stores the desired PID values in the data SRAM. There- 
after, the data SRAM can be re-programmed at any time 
by the main processor. Thus, the demultiplexing opera- 
tion can be dynamically altered in situ by the main proc- 
essor. However, once the main processor has config- 
ured the data SRAM, the demultiplexing operation itself 
is independent of the main processor. 
[0048] In accordance with the present invention, in 
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operation the transport controller core 320 takes the PID 
of the current transport packet header and transfers it 
on interconnect bus 404 to the search engine 322, the 
search engine 322 carrying out the operation of access- 
ing the data SRAM 400 to determine whether the PID is s 
associated with a transport packet which should be re- 
tained. The search engine 322 searches the PIDs stored 
in the data SRAM 400 for a match with the PID of the 
incoming data packet. 

[0049] Referring now to Figure 4, the operation of the 
search engine 322 will be described in further detail. 
[0050] The search engine 322 comprises a base ad- 
dress register 350, a match data register 352, a size reg- 
ister 354. an index register 358, control logic 360, an 
operate register 356, a comparator 362, a comparator 
364 an mcrementer 368, and an adder 366. 
[0051] The interconnect bus 404 comprises, in this 
embodiment, a transport controller write data bus signal 
TCWRDATA 4t0. a transport controller read data bus 
signal TCRDATA412, a transport controller address bus 
TCADDR 414. a tiansport controller request signal 
TCREQ 41G a transport controller grant signal TC- 
GHANT 416. and a transport controller read signal 
TCRD 420 The interconnect bus 406 comprises a 
memory nodrcss bus MEMADDR 430, a memory read 
data bus MEMRDDATA 428, a memory request signal 
MEMREQ 426, a memory grant signal MEMGRANT 
424. and a memory read signal MEMRD 422. 
[0052] The base address register 350, the match data 
register 352. the size register 354, and the operate reg- 
ister 356 all receive the transport controller write data 
bus TCWRDATA 410. The base address register 350, 
the match data register 352, the size register 354, and 
the operate register 356 are also all connected to pro- 
vide outputs on the transport controller read data bus 
TCRDDATA 412. 

[0053] The base address register 350 provides an 
output on lines 370 which form one input to the adder 
366, the other input to the adder 366 on lines 386 being 
provided by the index register 358. 
[0054] The match data register 352 provides an out- 
put on lines 372 which forms an input to the comparator 
362, the other input of the comparator 362 being provid- 
ed by the memory read data bus MEMRDDATA 428, and 
the output of the comparator 362 on lines 374 forming 
an input to the control logic 360. 

[0055] The size register 354 has an output on lines 
376 which forms an input to the comparator 364, the oth- 
er input to the comparator 364 being provided on lines 
378 by the index register 358, and the output of the com- 
parator 364 being provided on line 379 to the control 
logic 360. 

[0056] The output 386 of the index register 358 also 
forms the transport controller address bus TCADDR 
414. The index register 358 also receives on line 380 
an output signal of the incrementer 368, the incrementer 
368 receiving an input on line 382 from the control logic 
360. 
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[0057] The operate register 356 and control logic 360 
are interconnected via bidirectional signal line 384. The 
control logic 360 additionally receives as inputs the 
transport controller request signal TCREQ on line 416, 
the transport controller read signal TCRD on line 420, 
and the memory grant signal MEMGRANT on line 424. 
The control logic 360 additionally outputs the transport 
controller grant signal TCGRANT on line 418, the mem- 
ory read signal MEMRD on line 422, and the memory 
request signal MEMREQ on line 426. In addition, the 
control logic 360 outputs control signals on lines 361 to 
the base address register 350, match data register 352, 
size register 354 and index register 358. In addition, al- 
though not shown in Figure 4 for reasons of clarity, the 
base register 350, the match data register 352, the size 
register 354, the operate register 356, the index register 
358, the incrementer 368, and the control logic 360 all 
receive a system clock. 

[0058] As will now be described, the search engine 
322 is used by the transport controller core 320 to 
search a contiguous block of words within the data 
SRAM for the first match to a value, and to return an 
index to the transport controller core 320 so that the 
transport controller core 320 can find the location in the 
data SRAM of this match. The search engine must 
therefore be used once for every transport packet re- 
ceived. In the preferred embodiment of the present in- 
vention, the PID can have up to 48 possible values, and 
therefore the search engine must search through up to 
48 possible values of the PID stored in the data SRAM. 
The time taken to perform this function greatly affects 
the speed of the overall transport packet parsing, and 
therefore the provision of the search engine 322 dedi- 
cated to this particular operation, and relieving both the 
transport controller core 320 and the system processor 
of the task, enables a significant improvement in per- 
formance. 

[0059] The operate register 356 determines whether 
the search engine is operating or not: the operate reg- 
ister 356 is set to start the search engine, and cleared 
to stop the search engine. The contents of the base ad- 
dress register 350, the match data register 352, and the 
size register 354 must be set while the operate register 
356 is cleared, i.e. when the search engine is not oper- 
ating. The base address register 350 is set at the base 
address of memory where the search operation is to be- 
gin. The match data register 352 is set to store the PID 
of the incoming transport packet header, i.e. the search 
parameter used by the search engine. The size register 
354 is set to indicate the search range of the search en- 
gine, i.e. the range of addresses above the base ad- 
dress which are to be searched. The index register 358 
is initially cleared, and in operation as described here- 
inbelow, stores the current offset value from the base 
address of the address currently being accessed in the 
data SRAM. 

[0060] The base address register 350 , the match data 
register 352, the size register 354, and the operate reg- 
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ister 356 are all set by the transport controller core 320 
via the transport controller write data bus TCWRDATA 
410. The transport controller core 320 sets these regis- 
ters after a standard request/grant protocol is performed 
between the transport controller core 320 and the con- 
trol logic 360 of the search engine 322 via the transport 
controller request signal TCREQ41 6 and transport con- 
troller grant signal TCGRANT418. Thereafter, once the 
transport controller sets the operate register 356, the 
search engine begins searching under the control of the 
control logic 360 as described hereinafter. 
[0061] The control logic 360 of the search engine 322 
requests a memory access to the data SRAM 400 via 
the memory request signal MEMREQ on line 426, and 
if the request is granted receives the memory grant sig- 
nal MEMGRANT on line 424. This request/grant proto- 
col is a standard protocol. 

[0062] In response to the memory grant signal MEM- 
GRANT on line 424 : the control logic 360 controls the 
base address register 350 via control lines 361 to output 
the contents of the base address register 350 on the 
memory address bus MEMADDR 430 via the adder 366. 
At this stage, the index register is cleared, and therefore 
the memory address on bus MEMADDR 430 is the con- 
tents of the base address register alone, having had the 
value zero added thereto. The data accessed from the 
data SRAM 400 by the memory address on bus ME- 
MADDR 430 is received on the memory read data bus 
MEMRDDATA 428 and forms an input to the comparator 
362. The comparator 362 compares this accessed data 
with the PID in the match data register 352, and outputs 
the result thereof to the control logic 360 via line 374. 
[0063] If the comparator 362 does not find a match, 
then the control logic 360 controls the incrernenter 368 
to increment the value of the index register 358 by one 
address location, such that this is added to the value in 
the base address register 350, the value of the memory 
address on bus MEMADDR 430 thereby increasing by 
one memory location. Again, the accessed data at this 
memory location is returned on the memory read data 
bus MEMRDDATA 428 and compared in the comparator 
362. The operation of the search engine continues in 
this way until a match is found between the PID in the 
match data register 352 and the accessed data on the 
memory data bus MEMRDATA 428, or until each mem- 
ory location storing a possible PID value has been ac- 
cessed without a valid comparison being made. 
[0064] Each time the control logic 360 controls the in- 
crernenter 368 to increase the value in the index register 
358, the comparator 364 compares the value in the in- 
dex register 358 with the value in the size register 354. 
Once the value in the index register reaches the value 
in the size register 354, the comparator 364 sets its out- 
put on line 379 to the control logic 360. In response to 
the signal on line 379, the control logic 360 clears the 
operate register 356 to terminate operation of the search 
engine. Thus, in this way the search engine searches 
through the address range determined by the size reg- 



ister 354, and if no match is found, the operation of the 
search engine is terminated. 

[0065] If the PID in the match data register 352 is suc- 
cessfully matched to a PI D stored in the data SRAM, the 
comparator 362 indicates a match by setting its output 
on line 374 and, in response to the appropriate signal 
on line 374, the control logic 360 terminates the search 
operation by clearing the operate register 356, and the 
value stored in the index register will be the offset ad- 
dress of the matched PI D from the base address register 
350. 

[0066] The transport controller can monitor the state 
of the operate register 356 via the transport controller 
read data bus TCRDDATA 41 2, and when it detects that 
the search operation has been finished by the operate 
register 356 being cleared, the transport controller reads 
the contents of the index register 358 via the transport 
controller address bus 414. The most significant bit of 
the index register will be reserved to indicate whether a 
valid PID has been identified or not. That is, if the most 
significant bit of the index register is not set, then this 
will be indicative of the fact that the index register 358 
includes a value of the offset of the stored PID from the 
base address value. However, if the search has not 
found a match to the PID, the most significant bit of the 
index register 358 will be set (by the control logic 360 
responsive to a signal on line 379 from the computer 
364 indicating a match) and the transport controller will 
identify the setting of this bit and discard the incoming 
30 transport packet. 

[0067] From the value of the base address register 
350 and the value of the index register 358, where a 
match of the PID has been found, the transport control- 
ler will be able to identify the address to access in the 
■35 data SRAM 400 to locate various fields associated with 
the transport packet header. This operation will be de- 
scribed further hereinbelow with reference to Figure 5. 
[0068] It will be appreciated from the foregoing de- 
scription that both the search engine via interconnect 
40 bus 406 and the transport controller core via intercon- 
nect bus 404 can access the data SRAM 400. There- 
fore, some means of arbitration is provided between the 
transport controller core 320 and the search engine 322 
to determine which has access to the data SRAM 400 
is jn the event of a conflict caused by attempted simulta- 
neous access. Such arbitration may be provided by any 
circuitry known in the art, and the arbitration would pref- 
erably be such that the search engine always has prior- 
ity over the transport controller core for access to the 
so data SRAM 400. 

[0069] The data associated with each PID which is to 
be accessed from the data SRAM is preferably stored 
in several arrays of structures, each array being directly 
linked to the other with pointers precalculated by the 
>s system processor at initialisation time for fast access to 
information. The data associated with each PID which 
the transport controller core accesses is dependent up- 
on the particular operations which might be necessary 
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on the transport stream. For example, the payload of the 
transport stream may be scrambled, and the PID may 
have associated therewith stored in the data SRAM the 
appropriate descrambler keys which need to be re- 
turned via lines 112 from the transport controller 200 to 
the input module 100 for descrambling the transport 
packet payload. In addition, the PID is used to access 
information from the data SRAM which indicates wheth- 
er the transport packet payload is audio or video infor- 
mation which can be passed straight through the trans- 
port controller 200 to its output 502, or whether the pay- 
load of the transport packet is a section which must be 
filtered, preferably by being passed to the section filter 
312 of the transport controller 200 for filtering, or alter- 
natively under direct control of the transport controller 
core. There is also preferably information associated 
with the PID and stored in the data SRAM 400 concern- 
ing the status of buffers of the DMA controller 500. 
[0070] The splitting of the different information asso- 
ciated with a PID into independent arrays of structures 
allows the size of the overall information to be compact 
and gives more flexibility in configuration of the memory. 
Every PID can in fact have parts of data associated 
therewith in common with other PIDs, for example the 
same set of descrambling keys, and thus this set of de- 
scrambling keys, which may be associated with several 
PIDs, need only be stored once. The different PID types 
do not all require one instance of all the structures, for 
example information concerning the section filter status 
is needed only by transport packets which are sections, 
and not by other transport packets. This can also allow, 
with the same size of data SRAM available, the use of 
a different mix of PID types by just re-sizing the arrays 
of the DMA controller 500, section filter 312, and de- 
scrambling key arrays. 

[0071] Referring to Figure 5, the data SRAM 400 in- 
cludes a look-up table 450 which contains the active 
PIDs currently allocated. In the preferred embodiment 
this is an array of 48 locations, each location containing 
the value of an active PID. In addition there is an array 
452 that keeps the information of the stream status and 
the links with all the other arrays stored in the data 
SRAM. The slots, or sectors, of these arrays 450 and 
452 are linked such that information from the same PID 
resides at the same array offset. This gives a swift link 
between the arrays 450 and 452. 
[0072] Once the main PID data is accessed, it is pos- 
sible to check the status and configuration of the stream 
demultiplexing in the status words and get links to the 
output buffers of the DMA controller 500, keys for de- 
scrambling for use in the input module 100, and section 
filter status structures for use in section filtering by the 
section filter 312. These links are in the format of point- 
ers to the beginning of the correct structure of data need- 
ed. 

[0073] Referring to Figure 5, there is shown an exam- 
ple in which the PID of the current transport packet is 
171 . Thus the search engine 322 is pointing to this PID 



in the PID look-up table 450, the PID look-up table 450 
being the array through which the search engine search- 
es for the current PID of the current transport packet. 
The PID 171 in the PID look-up table 450 points via 

s pointer 460 to an array 452 of PID main information. The 
PID main information includes, typically, status words 
and pointers to the other fields. Thus, the array of PID 
main information for the PID of 171 points, in this exam- 
ple, via pointer 462 to the array of section filter states 

io 454 (the message packet is a section) and the appro- 
priate output 468 is generated for use by the section fil- 
ter. The array of PID main information 452 also points 
via pointer 464, in the case where the payload of the 
transport packet is scrambled, to the array of descram- 

75 bling keys. The output 470 is the appropriate descram- 
bling key for use by the input module 1 00. The array of 
PID main information also points via pointer 466 to the 
array of DMA configurations, and output 472 outputs the 
appropriate configuration information for use by the 

20 DMA controller 500. 

[0074] Each of the outputs 468, 470, and 472 are pro- 
vided to the transport controller core 320 via the inter- 
connect bus 404. the transport controller then takes the 
necessary action in accordance with information re- 

2S trieved from the data SRAM. 

[0075] Figure 6 illustrates an application of a program- 
mable transport interface, according to the present in- 
vention, in a digital television system. 
[0076] Figure 6 illustrates how digital television sig- 

30 nals 809, 811, and 813 can be transmitted via a cable, 
satellite or terrestrial television channel 852 and be 
viewed on a television 890. The first, second and third 
television signals 809, 811 and 813 each represent the 
audio and video signals necessary to recreate a televi- 

3S sion program on input to a television. The digital televi- 
sion signals 809, 811 and 813 are source encoded and 
channel encoded by a transmitter 850 to produce a mod- 
ulated analogue signal for transmission on the channel 
852. An integrated receiver decoder (also known as a 

40 set-top-box) 880 receives the modulated analogue sig- 
nal from the channel 652 and produces a video signal 
839 which operates the television 890. 
[0077] The operation of the transmitter 850 will now 
be explained. The transmitter includes a source encoder 

45 810 and a channel encoder 840. The source encoder 
includes - first, second and third MPEG-2 encoders 81 2, 
81 4 and 81 6; first second and third packetisers 818, 820 
and 822; first, second and third scramblers 824, 826 and 
828 and a multiplexer 830. The first, second and third 

50 MPEG-2 encoders respectively receive the first 809, 
second 811 and third 81 3 television signals and encode 
the signals to produce first, second and third elementary 
bit streams 815, 31 7 and 81 9. The first 818, second 820 
and third 822 packetisers respectively receive the first 

55 815, second 817 and third 819 elementary bit streams 
and packetise the elementary bit streams to produce 
first, second and third packetised elementary bit 
streams (PES) 821 , 823 and 825. The packetising of an 
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elementary bit stream includes creating a series of pack- 
ets which contain a packet header and a data portion, 
but which do not have any fixed length. The first 824, 
second 826 and third 828 scramblers receive respec- 
tively the first 821 , second 823 and third 825 packetised 
elementary bit streams (PES) and produce first, second, 
and third scrambled PES 827, 829 and 831 . Each of the 
scramblers scrambles only the data portion of each 
packetised elementary bit stream it receives and does 
not scramble the packet header. 
[0078] The multiplexer 830 receives as inputs pack- 
etised sections of tables on line 841, and the first, sec- 
ond and third scrambled PES 827, 829 and 831 , and 
produces a transport stream from one of its inputs on 
line 601 The packetised sections of tables 841 contain 
information which allows the set -top-box 880 to effect 
source decoding and produce the video signals 839. 
The information is stored in a tabular format where each 
taole contains a number of sections and each section is 
Iransmilled individually. 

[0079] The multiplexer 830 produces a transport 
stream 801 such as that illustrated in Figure 1 as dis- 
cussed tn detail hereinabove. The transport stream in- 
cludes a number of transport packets 2 wherein each 
transport packet contains a transport packet header 4 
and a transport packet payload 6. The transport packets 
have a fixed length. In the digital MPEG-2 video broad- 
cast (DVB) standard the transport packet is 188 bytes 
in length The transport packets are shorter in length 
than the packets in the packetised elementary stream 
(PES) Consequently, a packet from the first scrambled 
PES 327 will be spread over a number of transport pack- 
ets and these transport packets will be multiplexed with 
transport packets derived from the packetised sections 
of tables 841 and the second and third scrambled PES 
829, 831. The transport stream is then supplied on line 
801 to the channel encoder 840 to produce the modu- 
lated analogue signal for transmission on the channel 
852. 

[0080] The channel encoder 840 includes circuitry 

832 for forward error correcting (FEC) the transport 
stream on line 801 and a digital-to-analogue converter 
(DAC) for converting the signal from digital to analogue 
to produce an analogue signal 833. The analogue signal 

833 is modulated and up-converted to a transmission 
frequency by the circuit 834 to produce the modulated 
analogue signal which is then transmitted into the chan- 
nel 852. 

[0081] The operation of the set-top-box 880 will now 
be explained. The set-top-box 880 includes a channel 
decoder 860 and a source decoder 870. The channel 
decoder 860 receives the modulated analogue signal on 
the channel 852 and produces the transport stream 802 
which it supplies to the source decoder 870. 
[0082] The channel decoder 860 includes circuitry 
862 for tuning to the modulated analogue signal on the 
channel 852, and for downcon verting and demodulating 
the modulated analogue signal on the channel 852 to 



produce an analogue signal 837. The analogue signal 
837 is converted from analogue to digital in an analogue 
to digital converter (ADC) and forward error corrected 
(FEC) by the circuitry 864 to reproduce the transport 

5 stream as signal 802. 

[0083] The source decoder 870 receives the transport 
stream 801 and produces the video signal 839. The 
source decoder 870 includes a programmable transport 
interface (PTI) 882 and MPEG-2 decoder 872. The PTI 

10 960 demultiplexes the transport stream 802, selects the 
transport packets 2 carrying information relating to a 
particular television program, and descrambles these 
selected transport packets to produce a data output 
stream 880, which is, in fact, the packetised elementary 

'5 bit stream associated with the selected television pro- 
gram. The MPEG-2 decoder 872 receives the data out- 
put stream 880 and produces the video signal 839 which 
is supplied to the television 890. The television 890 dis- 
plays the selected television program. 



Claims 

1. A receiver for demultiplexing a digital data stream, 
the digital data stream including data packets each 
having a packet identifier, so as to retain only those 
data packets required by the receiver, the receiver 
comprising: 

input circuitry for receiving the digital data 
stream; 

a memory for storing packet identifiers of data 
packets required by the receiver; 
a first control circuit for controlling the storage 
in the memory of the packet identifiers; 
a second control circuit for extracting a packet 
identifier from a data packet in the digital data 
stream input to the input circuitry; and 
a third control circuit for receiving the extracted 
packet identifier and determining whether such 
matches one of the packet identifiers stored in 
the memory, and for setting a match signal to 
the second control circuit responsive to a 
match, wherein the second control circuit de- 
multiplexes the input data packet responsive to 
the match signal. 

2. The receiver of claim 1 in which the third control cir- 
cuit outputs the address in the memory of the ex- 
tracted packet identifier responsive to a match, and 
the second control circuit accesses that address to 
retrieve control information associated with the 
packet identifier. 

3. The receiver of claim 2 wherein responsive to the 
control information the second control circuit con- 
trols the transfer of the input data packet to a des- 
tination address identified by the control informa- 
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tion. 

4. The receiver of claim 2, wherein responsive to the 
control informatbn the second control circuit proc- 
esses the input data packet and transfers the proc- 5 
essed input data packet to a destination address 
identified by the control information. 

5. The receiver of any one of claims 1 to 4 wherein 
responsive to the match signal not being set, the io 
second control circuit discards the input data pack- 
et. 

6. The receiver of any preceding claim in which the 
digital data stream is an MPEG-2 encoded stream, is 

7. The receiver of claim 6 when dependent on claim 3 
in which the input data packet comprises a pack- 
etised elementary stream. 

20 

8. The receiver of claim 6 when dependent on claim 4 
in which the input data packet comprises program 
specific information, and the receiver further com- 
prises a filter controlled by the second control circuit 

for filtering sections in the input data packet so as zs 
to retain only those data packets having sections 
required by the receiver. 

9. The receiver of any preceding claim in which first 
control circuit is a receiver processor, the second 30 
control circuit is a transport processor, and the third 
control circuit is a search engine. 



10. A set-top-box including a receiver according to any 
preceding claim. 35 

11. A method of demultiplexing a digital data stream in- 
put to a receiver, the digital data stream including 
data packets each having a packet identifier, so as 

to retain only those data packets required by the re- 40 
ceiver, comprising the steps of: 

inputting the digital data stream; 

storing in a memory, under the control of a first 

control circuit, all packet identifiers of data 45 

packets required by the receiver; 

extracting, under the control of a second control 

circuit, a packet identifier from a data packet in 

the input digital data stream; 

determining, under the control of a third control 50 
circuit, whether the extracted packet identifier 
matches one of the stored packet identifiers; 
setting a match signal responsive to a match 
determined by the third control circuit; and 
demultiplexing, under the control of the second 55 
control circuit, the input data packet responsive 
to the match signal. 



12. The method of claim 11, further comprising the 
steps of: 

outputting, responsive to a match, the address 
in memory of the extracted packet identifier; 
accessing, under the control of the second con- 
trol circuit, the address in memory; and 
retrieving control information associated with 
the packet identifier and stored at such ad- 
dress. 

1 3. The method of claim 1 2 further comprising the step 
of: 

transferring, under the control of the second 
control circuit, the input data packet to a desti- 
nation address identified by the control infor- 
mation. 

1 4. The method of claim 1 2 further comprising the steps 
of: 

processing, under the control of the second 
control circuit, the input data packet in depend- 
ence on the control information; and 
transferring, under the control of the second 
control circuit, the processed input data packet 
to a destination address identified by the con- 
trol information. 

15. The method of any one of. claims 11 to 14 in which 
the step of demultiplexing comprises discarding the 
input data packet responsive to the match signal not 
being set. 

16. The method of any one of claims 11 to 1 5 in which 
the digital data stream is an MPEG-2 encoded 
stream. 

17. The method of claim 16 when dependent on claim 

1 3 in which the input data packet comprises a pack- 
etised elementary stream. 

18. The method of claim 16 when dependent on claim 

14 in which the input data packet comprises pro- 
gram specific information, and wherein said 
processing step comprises: 

filtering sections in the input data packet so as 
to retain only those data packets having sec- 
tions required by the receiver. 

19. The method of any one of claims 11 to 18 in which 
the step of determining a match comprises system- 
atically searching the memory. 

20. A method of decoding a broadcast digital data sig- 
nal in a set-top-box comprising the steps of any one 
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of claims 11 to 19. 
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